Skip to content

Fix Gradle build error: unresolved FilterType reference#143

Merged
omeritzics merged 6 commits intomainfrom
fix-gradle-filter-type
Feb 15, 2026
Merged

Fix Gradle build error: unresolved FilterType reference#143
omeritzics merged 6 commits intomainfrom
fix-gradle-filter-type

Conversation

@omeritzics
Copy link
Owner

@omeritzics omeritzics commented Feb 15, 2026

User description

  • Import FilterConfiguration.FilterType.* instead of VariantOutputConfiguration.FilterType.*
  • Simplify FilterType.ABI reference to use imported type
  • Fixes build failure on line 136 of build.gradle.kts

PR Type

Bug fix


Description

  • Fixed unresolved FilterType reference in Gradle build configuration

  • Corrected import to use FilterConfiguration.FilterType instead of VariantOutputConfiguration.FilterType

  • Removed unused ApkVariantOutputImpl import

  • Simplified FilterType.ABI reference to use imported type directly


Diagram Walkthrough

flowchart LR
  A["build.gradle.kts"] -->|Remove unused import| B["ApkVariantOutputImpl"]
  A -->|Update import| C["FilterConfiguration.FilterType.*"]
  A -->|Simplify reference| D["FilterType.ABI"]
Loading

File Walkthrough

Relevant files
Bug fix
build.gradle.kts
Fix FilterType import and reference in build configuration

android/app/build.gradle.kts

  • Removed unused import of
    com.android.build.gradle.internal.api.ApkVariantOutputImpl
  • Corrected import statement to use
    com.android.build.api.variant.FilterConfiguration.FilterType.*
  • Simplified FilterType reference from fully qualified
    com.android.build.api.variant.VariantOutputConfiguration.FilterType.ABI
    to FilterType.ABI
  • Fixes build failure caused by incorrect FilterType import
+1/-2     

- Import FilterConfiguration.FilterType.* instead of VariantOutputConfiguration.FilterType.*
- Simplify FilterType.ABI reference to use imported type
- Fixes build failure on line 136 of build.gradle.kts
@gemini-code-assist
Copy link

Summary of Changes

Hello @omeritzics, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses and resolves a critical Gradle build error by updating the FilterType import path and streamlining its subsequent usage. The changes ensure that the build process correctly identifies and utilizes the FilterType enumeration, thereby fixing the compilation failure and improving code clarity by removing an unused import.

Highlights

  • Gradle Build Fix: Resolved a Gradle build failure by correcting the import statement for FilterType and simplifying its usage within the build.gradle.kts file.
  • Import Correction: Switched the FilterType import from com.android.build.api.variant.VariantOutputConfiguration.FilterType.* to com.android.build.api.variant.FilterConfiguration.FilterType.*.
  • Code Simplification: Simplified the reference to FilterType.ABI by leveraging the corrected import, removing the need for the fully qualified name.
  • Unused Import Removal: Removed an unnecessary import for com.android.build.gradle.internal.api.ApkVariantOutputImpl.
Changelog
  • android/app/build.gradle.kts
    • Updated the import path for FilterConfiguration.FilterType.
    • Removed an unused import for ApkVariantOutputImpl.
    • Simplified the reference to FilterType.ABI by using the newly imported type.
Activity
  • No human activity has been recorded on this pull request yet.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@github-actions
Copy link

github-actions bot commented Feb 15, 2026

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

@qodo-code-review
Copy link

qodo-code-review bot commented Feb 15, 2026

PR Compliance Guide 🔍

(Compliance updated until commit 27e4f5a)

Below is a summary of compliance checks for this PR:

Security Compliance
🟢
No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🎫 No ticket provided
  • Create ticket/issue
Codebase Duplication Compliance
Codebase context is not defined

Follow the guide to enable codebase context checks.

Custom Compliance
🟢
Generic: Comprehensive Audit Trails

Objective: To create a detailed and reliable record of critical system actions for security analysis
and compliance.

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Meaningful Naming and Self-Documenting Code

Objective: Ensure all identifiers clearly express their purpose and intent, making code
self-documenting

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Robust Error Handling and Edge Case Management

Objective: Ensure comprehensive error handling that provides meaningful context and graceful
degradation

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Secure Error Handling

Objective: To prevent the leakage of sensitive system information through error messages while
providing sufficient detail for internal debugging.

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Secure Logging Practices

Objective: To ensure logs are useful for debugging and auditing without exposing sensitive
information like PII, PHI, or cardholder data.

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Security-First Input Validation and Data Handling

Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent
vulnerabilities

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

  • Update
Compliance status legend 🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

Previous compliance checks

Compliance check up to commit 7b94b98
Security Compliance
🟢
No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🎫 No ticket provided
  • Create ticket/issue
Codebase Duplication Compliance
Codebase context is not defined

Follow the guide to enable codebase context checks.

Custom Compliance
🟢
Generic: Comprehensive Audit Trails

Objective: To create a detailed and reliable record of critical system actions for security analysis
and compliance.

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Meaningful Naming and Self-Documenting Code

Objective: Ensure all identifiers clearly express their purpose and intent, making code
self-documenting

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Robust Error Handling and Edge Case Management

Objective: Ensure comprehensive error handling that provides meaningful context and graceful
degradation

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Secure Error Handling

Objective: To prevent the leakage of sensitive system information through error messages while
providing sufficient detail for internal debugging.

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Secure Logging Practices

Objective: To ensure logs are useful for debugging and auditing without exposing sensitive
information like PII, PHI, or cardholder data.

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

Generic: Security-First Input Validation and Data Handling

Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent
vulnerabilities

Status: Passed

Learn more about managing compliance generic rules or creating your own custom rules

@qodo-code-review
Copy link

qodo-code-review bot commented Feb 15, 2026

PR Code Suggestions ✨

Latest suggestions up to 0b4fe23

CategorySuggestion                                                                                                                                    Impact
Incremental [*]
Guard UI calls after await

In the refresh method, add an if (mounted) check within the catch block before
calling showError to prevent errors if the widget is disposed during the async
operation.

lib/pages/apps.dart [182-201]

 Future<List<App>> refresh() async {
   HapticFeedback.lightImpact();
   if (!mounted) return <App>[];
 
   setState(() {
     refreshingSince = DateTime.now();
   });
 
   try {
     return await context.read<AppsProvider>().checkUpdates();
   } catch (e) {
-    showError(e is Map ? e['errors'] : e, context);
+    if (mounted) {
+      showError(e is Map ? e['errors'] : e, context);
+    }
     return <App>[];
   } finally {
     if (!mounted) return;
     setState(() {
       refreshingSince = null;
     });
   }
 }
  • Apply / Chat
Suggestion importance[1-10]: 8

__

Why: The suggestion correctly identifies a potential runtime error from using BuildContext in an async gap and proposes the standard if (mounted) guard, which is a crucial fix for widget lifecycle issues.

Medium
Clamp progress indicator value

Clamp the CircularProgressIndicator.value between 0.0 and 1.0 to prevent
potential assertion errors if the downloadProgress value is ever outside the
0-100 range.

lib/pages/apps.dart [988-998]

 child: Builder(
   builder: (_) {
     final progress = listedApps[index].downloadProgress;
     if (progress == null) return const SizedBox.shrink();
+
+    final value = progress >= 0 ? (progress / 100).clamp(0.0, 1.0) as double : null;
+
     return Center(
       child: CircularProgressIndicator(
-        value: progress >= 0 ? progress / 100 : null,
+        value: value,
       ),
     );
   },
 ),
  • Apply / Chat
Suggestion importance[1-10]: 6

__

Why: The suggestion correctly points out that CircularProgressIndicator.value must be between 0.0 and 1.0 and proposes using clamp to prevent potential assertion errors, which improves the code's robustness.

Low
Possible issue
Render overlay only when downloading

Wrap the Positioned.fill widget in a condition to only show the download overlay
and progress indicator when downloadProgress is not null, fixing a UI
regression.

lib/pages/apps.dart [982-1001]

-Positioned.fill(
-  child: Container(
-    decoration: BoxDecoration(
-      borderRadius: BorderRadius.circular(12),
-      color: Colors.black45,
-    ),
-    child: Builder(
-      builder: (_) {
-        final progress = listedApps[index].downloadProgress;
-        if (progress == null) return const SizedBox.shrink();
-        return Center(
-          child: CircularProgressIndicator(
-            value: progress >= 0 ? progress / 100 : null,
-          ),
-        );
-      },
+final progress = listedApps[index].downloadProgress;
+if (progress != null)
+  Positioned.fill(
+    child: Container(
+      decoration: BoxDecoration(
+        borderRadius: BorderRadius.circular(12),
+        color: Colors.black45,
+      ),
+      child: Center(
+        child: CircularProgressIndicator(
+          value: progress >= 0 ? progress / 100 : null,
+        ),
+      ),
     ),
   ),
-),

[To ensure code accuracy, apply this suggestion manually]

Suggestion importance[1-10]: 7

__

Why: The suggestion correctly identifies a functional regression where a refactoring causes a dimming overlay to be permanently visible on all app tiles, instead of only on those with an active download.

Medium
  • More

Previous suggestions

✅ Suggestions up to commit 0b4fe23
CategorySuggestion                                                                                                                                    Impact
Possible issue
Pass provider into refresh

To fix a scope error, modify the refresh() function to accept an AppsProvider as
a parameter, as it was moved out of the build method where the provider was
locally defined.

lib/pages/apps.dart [182-198]

-refresh() {
+refresh(AppsProvider appsProvider) {
   HapticFeedback.lightImpact();
   setState(() {
     refreshingSince = DateTime.now();
   });
   return appsProvider
       .checkUpdates()
       .catchError((e) {
         showError(e is Map ? e['errors'] : e, context);
         return <App>[];
       })
       .whenComplete(() {
         setState(() {
           refreshingSince = null;
         });
       });
 }

[Suggestion processed]

Suggestion importance[1-10]: 10

__

Why: The PR moves the refresh() function outside the build method, but refresh() depends on appsProvider which is only defined locally within build. This will cause a compile-time error, so the suggestion correctly identifies and fixes a critical bug.

High
Incremental [*]
Make filter comparison more robust
Suggestion Impact:Replaced the string-based comparison of filterType.name with a direct enum comparison against FilterType.ABI, making the check more robust than the original string match.

code diff:

             val abiFilter = output.filters.find {
-                it.filterType.name == "ABI"
+                it.filterType == com.android.build.api.variant.FilterConfiguration.FilterType.ABI
             }

Use a case-insensitive comparison for the ABI filter type to make the check more
robust against potential API changes.

android/app/build.gradle.kts [134]

-it.filterType.name == "ABI"
+it.filterType.name.equals("ABI", ignoreCase = true)

[Suggestion processed]

Suggestion importance[1-10]: 4

__

Why: The suggestion correctly identifies that comparing an enum by its string name is brittle and proposes using a case-insensitive comparison, which slightly improves the code's robustness.

Low
Suggestions up to commit dae5794
CategorySuggestion                                                                                                                                    Impact
Incremental [*]
Guard against null progress

Re-introduce a null check for downloadProgress before rendering the
CircularProgressIndicator to prevent a crash when its value is null.

lib/pages/apps.dart [985-991]

-child: Center(
-  child: CircularProgressIndicator(
-    value: listedApps[index].downloadProgress! >= 0
-        ? listedApps[index].downloadProgress! / 100
-        : null,
-  ),
+child: Builder(
+  builder: (_) {
+    final progress = listedApps[index].downloadProgress;
+    if (progress == null) return const SizedBox.shrink();
+    return Center(
+      child: CircularProgressIndicator(
+        value: progress >= 0 ? progress / 100 : null,
+      ),
+    );
+  },
 ),

[Suggestion processed]

Suggestion importance[1-10]: 9

__

Why: The suggestion correctly points out that removing the if (downloadProgress != null) check from the original code and using the null-check operator (!) will cause a runtime crash when downloadProgress is null. The proposed solution correctly re-introduces the null check, fixing a critical bug.

High
Stabilize ABI filter detection

To improve build script stability across Android Gradle Plugin versions, compare
the filter type by its string name (it.filterType.name == "ABI") instead of by
its enum value.

android/app/build.gradle.kts [134]

-it.filterType == com.android.build.api.variant.FilterConfiguration.FilterType.ABI
+it.filterType.name == "ABI"

[Suggestion processed]

Suggestion importance[1-10]: 5

__

Why: The suggestion proposes a change to make the build script more resilient to future Android Gradle Plugin API changes by comparing the enum's name as a string. This is a good practice for maintainability, though the current code is correct for the version being used.

Low
Possible issue
Guard setState after disposal

Refactor the refresh method to be async and check if the widget is mounted
before calling setState to prevent potential runtime errors.

lib/pages/apps.dart [182-198]

-refresh() {
+Future<List<App>> refresh() async {
   HapticFeedback.lightImpact();
+  if (!mounted) return <App>[];
+
   setState(() {
     refreshingSince = DateTime.now();
   });
-  return appsProvider
-      .checkUpdates()
-      .catchError((e) {
-        showError(e is Map ? e['errors'] : e, context);
-        return <App>[];
-      })
-      .whenComplete(() {
-        setState(() {
-          refreshingSince = null;
-        });
-      });
+
+  try {
+    return await context.read<AppsProvider>().checkUpdates();
+  } catch (e) {
+    showError(e is Map ? e['errors'] : e, context);
+    return <App>[];
+  } finally {
+    if (!mounted) return;
+    setState(() {
+      refreshingSince = null;
+    });
+  }
 }

[Suggestion processed]

Suggestion importance[1-10]: 7

__

Why: The suggestion correctly points out a potential "setState() called after dispose()" error and proposes a robust solution using async/await and checking the mounted property, which improves the code's reliability.

Medium
✅ Suggestions up to commit 7b94b98
CategorySuggestion                                                                                                                                    Impact
Possible issue
Import FilterType enum class
Suggestion Impact:The wildcard import was removed and the ABI reference was changed to a fully qualified FilterType.ABI, avoiding the resolution issue without adding the suggested direct import.

code diff:

@@ -1,6 +1,5 @@
 import java.io.FileInputStream
 import java.util.Properties
-import com.android.build.api.variant.FilterConfiguration.FilterType.*
 
 plugins {
     id("com.android.application")
@@ -132,7 +131,7 @@
     onVariants { variant ->
         variant.outputs.forEach { output ->
             val abiFilter = output.filters.find {
-                it.filterType == FilterType.ABI
+                it.filterType == com.android.build.api.variant.FilterConfiguration.FilterType.ABI
             }

Replace the wildcard import of FilterType with a direct import of the enum class
to ensure FilterType.ABI resolves correctly.

android/app/build.gradle.kts [3]

-import com.android.build.api.variant.FilterConfiguration.FilterType.*
+import com.android.build.api.variant.FilterConfiguration.FilterType
Suggestion importance[1-10]: 9

__

Why: The suggestion correctly identifies that the wildcard import FilterType.* is incompatible with the usage FilterType.ABI on line 135, which would cause a build failure. Importing the enum class directly as suggested is the correct fix.

High

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request correctly resolves a Gradle build error. The change to use FilterType.ABI from the imported com.android.build.api.variant.FilterConfiguration.FilterType is correct and fixes the unresolved reference issue. Additionally, removing the unused import com.android.build.gradle.internal.api.ApkVariantOutputImpl is a good code hygiene practice. The changes are straightforward and effective. Excellent work.

omeritzics and others added 2 commits February 15, 2026 19:02
Co-authored-by: qodo-code-review[bot] <151058649+qodo-code-review[bot]@users.noreply.github.com>
Co-authored-by: qodo-code-review[bot] <151058649+qodo-code-review[bot]@users.noreply.github.com>
Repository owner deleted a comment from qodo-code-review bot Feb 15, 2026
Repository owner deleted a comment from qodo-code-review bot Feb 15, 2026
@omeritzics omeritzics merged commit df863fe into main Feb 15, 2026
4 of 7 checks passed
omeritzics and others added 3 commits February 15, 2026 20:37
- Remove problematic import and use full qualified name
- Use com.android.build.api.variant.FilterConfiguration.FilterType.ABI
- Fixes unresolved reference error on line 135
- Add missing dart:math import for math.max usage
- Fix duplicate Positioned.fill widgets in apps.dart
- Remove incorrect 'label' parameters, use 'child' instead
- Move refresh() method outside build() method
- Fix bracket mismatches and syntax errors
- Resolve AppsFilter class and openAppById method issues
Co-authored-by: qodo-code-review[bot] <151058649+qodo-code-review[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant